Software is a huge industry producing the most complicated data-driven systems ever created. Developing large software systems is an extremely complex, team-oriented, engineering activity. For instance, FIG. 2 illustrates general "objects" relating to a software project, and particularly, a software "release" 10, shown at the apex of a tree. A software release may be viewed from three different perspectives: a functional view 12, organizational view 14 and structural view 16. Each of these perspectives appears as a column in FIG. 2.
The functional perspective 12 views a software release based on the various capabilities it provides to customers. A set of software capabilities are collected together and packaged into a release for customers. This categorization is useful because it defines a customer delivery against which deadlines are cast. In addition, it is commonly used as an organizing factor for the development team producing the release.
The organizational perspective 14 focuses on the people involved in a software production process. The development team is usually divided into departments with each department in turn having its own hierarchy of groups and engineers. This categorization is useful for providing human links for resolving or following up on problems.
Finally, the structural perspective 16 views software artifacts including code, requirements documents, and other information kept in version management databases. At the highest level the code is divided into subsystems. Within each subsystem are modules, and within each module are source code files. A multi-million line software project may be partitioned into tens of subsystems, thousands of modules, and hundreds of thousands of files. For each file, the version management system maintains the complete history, including: a) the date and time of every change, b) lines affected, c) reason for the change, d) functionality added by the change for code additions, e) the fault repaired for error correcting code, and f) the like.
Databases associated with software projects are a rich, under-utilized resource for understanding software production. Large databases associated with a large software production project, however, make data unfeasible to read textually and its lack of structure frustrates statistical analysis tools. The challenge exists to extract information from the databases and present it to software engineers and managers in a useful and actionable form.
Thus, a need exists for a way to visually represent abstract project-management data, and, particularly, to abstract data related to software production, e.g., data relating to the overall task of efficiently managing and processing resources, both human and machine, for a software project. By making the information related to software visible, software engineers may cope with the complexity inherent in, and project managers may better understand, the software process. This should improve productivity in the software production process.
Over the last several years many techniques and systems have appeared for visualizing algorithms, code text, and other information associated with software data. Much of this research has focused on improving individual programmer productivity and has not been directed to visualizing software data associated with team productivity, i.e., project management. In large scale systems with thousands of programmers, the team-oriented aspects of the process and management decisions dominate the effects of individuals, no matter how talented and productive individuals are.
One prior art method of viewing multi-dimensional objects is through linked scatterplots, such as described in R. A. Becker and W. S. Cleveland, "Brushing Scatterplots," Technometrics, Vol. 29, 1987, pp. 127-142. However, this method does not enable the properties of a data element corresponding to a "real world" entity, e.g., a source code file or a person, to be grouped together visually.
Another prior art method for presenting multi-dimensional data is to employ visual metaphors embodied in glyphs, for example, as described in H. Chernoff, "The Use of Faces to Represent Points in k-Dimensional Space Graphically", Journal of the American Statistical Association, 1973, pp. 957-968 and, in the reference "Iconographic Displays for Visualizing Multidimensional Data," Proceedings I.E.E.E. Conference on systems, Man, and Cybernetics, 1988, pp. 514-519, by R. M. Pickett and G. Grinstein. However, the glyphs taught in these references focus on encoded attributes of discrete data, are non-color, and do not facilitate presentation of complex software data or project management data.